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Abstract 

An  approach  to  software  development  problems  is  presented,  and  illustrated 
by  an  example.  The  approach  is  based  on  the  ideas  of  problem  frames  and 
structuring  specifications  by  views.  It  is  claimed  that  decompositions  ob¬ 
tained  by  this  approach  result  in  a  more  effective  separation  of  concerns, 
and  that  the  resulting  components  are  more  likely  to  be  reusable  than  those 
obtained  by  more  conventional  approaches.  The  characteristics  of  desirable 
integration  mechanisms  are  discussed,  together  with  some  other  considera¬ 
tions  arising  out  of  the  approach  presented. 


Accession  Fo,' 

NTIS  CRAii 
DTIC  TAB 
Unenrionnc-;.:.! 
Jnstificctioi: 


By . 

Distribuhon  / 


r\  'Jc ! -• 


Av/au  a  n 


Dist 


1  Introduction 


Problem  decomposition  serves  two  purposes.  By  decomposing  a  large  prob¬ 
lem  into  smaller  subproblems  we  hope  to  master  its  complexity:  the  smaller 
subproblems  should  be  simpler  than  the  large  problem.  By  the  same  decom¬ 
position  we  hope  to  factor  out  subproblems  that  are  already  solved,  and  to 
re-use  their  existing  solutions. 

Hierarchical  decomposition  can  rarely  achieve  these  goals.  It  is  not  diffi¬ 
cult  to  sketch  a  plausible  hierarchy  of  procedures,  but  very  difficult  indeed 
to  be  sure  that  each  successive  level  of  decomposition  is  making  the  task  eas¬ 
ier  and  not  harder:  a  smaller  problem  is  not  necessarily  a  simpler  problem. 
The  constraints  imposed  by  the  difficulty  of  finding  a  workable  hierarchical 
decomposition  leave  too  little  freedom  for  recognising  and  exploiting  oppor¬ 
tunities  for  re-use. 

This  is  not  surprising.  Hierarchical  structure  is  extremely  specialised. 
Few  problem  domains,  and  even  fewer  problems,  exhibit  hierarchical  struc¬ 
ture.  Instead,  both  problems  and  problem  domains  usually  exhibit  parallel 
structure.  When  a  problem  with  an  essentially  parallel  structure  is  forced 
into  a  hierarchical  decomposition,  the  resulting  components  are  likely  to  be 
unsatisfactory  in  both  the  problem  and  the  solution  domain. 

The  problem  domain,  for  example,  may  be  decomposed  into  domain  en¬ 
tities,  viewed  as  agents  [8,  2].  The  component  for  each  agent  will  then 
inevitably  entangle  different  aspects  of  its  behaviour  that  are  unlikely  to 
reappear  in  exactly  that  combination  in  any  other  problem.  In  the  solution 
domain  the  same  difficulty  is  found  in  a  different  context.  Each  hierarchically 
derived  module  must  serve  several  computational  purposes  simultaneously: 
the  particular  combination  of  purposes  is  unlikely  to  be  useful  elsewhere. 
Essentially,  this  is  why  libraries  of  reusable  modules  have  proved  so  disap¬ 
pointing,  except  in  applications  such  as  numerical  computation  and  window 
interface  implementation,  where  the  problem  domains  and  problems  are  al¬ 
ready  highly  standardised. 

It  is  parallel  structure,  and  the  benefits  of  a  decomposition  that  respects 
its  nature,  that  characterises  the  present  approach  and  other  approaches 
based  on  the  notion  of  viewpoints  [10,  9].  The  approach  presented  in  this 
paper  combines  two  ingredients,  both  of  which  aim  to  exploit  parallel  struc¬ 
turing  of  problems  and  of  problem  domains.  They  are:  the  idea  of  problem 
frames  [6,  7];  and  the  idea  of  structuring  Z  specifications  as  views  [4]. 
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A  problem  frame  is  a  template  characterising  a  class  of  simple  problems — 
that  is,  problems  for  which  a  reliable  solution  method  is  known.  It  also 
characterises  a  class  of  problem  whose  solutions  are  likely  to  be  reusable. 
In  general,  different  problem  frames  invite  the  use  of  different  specification 
languages — sometimes  more  than  one  for  a  frame.  However,  it  is  not  our 
purpose  here  to  discuss  multiparadigm  specification  [12],  which  is  largely 
orthogonal  to  the  immediate  concerns  of  this  paper  (although  not  orthogonal 
to  problem  decomposition  generally).  We  have  therefore  chosen  to  use  Z 
for  all  the  problem  frames:  partly  because  this  avoids  some  still  unsolved 
difficulties  of  integrating  specifications  written  in  different  languages,  and 
partly  because  the  syntactic  mechanisms  of  Z  offer  a  number  of  features  that 
are  convenient  for  conjoining  parallel  specifications. 

The  approach  is  illustrated  by  an  example  problem:  the  control  of  a  pack¬ 
age  routing  machine  [11,  1].  We  show  the  decomposition  of  the  problem  into 
three  subproblems,  or  views,  that  fit  into  three  problem  frames;  the  specifi¬ 
cation  of  each  view;  and  the  connection  of  the  subproblem  views  into  a  single 
specification.  In  a  section  at  the  end  of  the  paper  we  discuss  some  general 
aspects  of  our  approach.  We  also  discuss  some  difficulties  of  view  integra¬ 
tion  as  they  appear  in  Z  and  other  languages,  and  outline  some  desirable 
properties  of  an  integration  mechanism. 

For  convenience,  the  complete  specification  is  gathered  together  at  the 
end  of  the  paper,  in  an  Appendix. 


2  Problem  Frames 

A  problem  frame  [6,  7]  is  a  structure  of  principal  parts  and  a  solution  task. 
Each  principal  part  is  one  of  the  following: 

•  The  machine  to  be  constructed — that  is,  to  be  described  by  the  software 
being  developed. 

•  A  part  of  the  environment  or  domain  of  the  problem. 

•  A  required  relationship  among  parts  of  the  environment  or  domain. 

The  solution  task  is  always  to  construct  the  machine  so  that  it  brings  about 
or  maintains  the  required  relationships. 
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Particular  problem  frames  are  specialised  to  particular  problem  classes. 
A  particular  problem  frame  can  be  thought  of  as  a  template  to  be  fitted 
over  a  problem;  the  principal  parts  of  the  frame  are  identified  with  parts 
and  aspects  of  the  problem’s  system,  environment,  and  requirements.  When 
a  frame  is  fitted  to  a  problem  in  this  way,  it  is  said  to  be  applied  to  the 
problem.  It  then  guides  the  choice  and  use  of  an  appropriate  method  for 
solving  the  problem.  The  purpose  of  identifying  and  studying  particular 
problem  frames  is  to  build  up  a  repertoire  of  problem  classes,  each  having  at 
least  one  well-understood  and  reliable  solution  method. 

Problem  frames  must  be  simple  if  they  are  to  be  useful.  But  realistic 
problems  are  rarely  simple.  The  complexity  of  a  realistic  problem  can  be 
regarded  as  a  parallel  composition  of  two  or  more  problem  frames.  Problem 
decomposition  is  then  the  recognition  of  the  appropriate  problem  frames  and 
the  identification  of  their  principal  parts.  A  problem  frame  applied  in  this 
way  has  something  in  common  with  an  instantiated  Viewpoint  [9],  which 
incorporates  a  representation  scheme,  a  development  process,  and  an  area  of 
concern  in  the  problem  domain. 

In  different  problem  frames  the  principal  parts  have  different  character¬ 
istics  and  are  differently  connected.  Many  problem  frames  are  needed,  to 
accommodate  the  many  parts  and  aspects  of  realistic  problems.  Here  we 
outline  only  three  particular  problem  frames,  chosen  because  they  are  the 
frames  we  will  use  in  our  example  problem. 

2.1  Control  Frame 

The  Control  problem  frame  might  be  used  for  a  problem  such  as  the  control 
of  a  simple  level  crossing  in  a  railway.  The  frame  has  three  principal  parts: 

•  The  Controller^  which  is  the  machine  to  be  built. 

•  The  Controlled  Domain,  which  is  a  dynamic  part  of  the  problem  en¬ 
vironment.  The  Controlled  Domain  is  connected  directly  to  the  Con¬ 
troller.  for  example,  sensing  the  arrival  of  a  train,  and  switching  on  the 
motor  that  raises  and  lowers  the  barrier  are  events  both  in  the  machine 
and  in  the  domain.  The  Controlled  Domain  is  partly  autonomous 
the  arrival  of  the  train  requires  no  external  stimulus.  It  is  also  partly 
reactive — when  the  motor  is  switched  on  the  barrier  will  rise  or  fall.  It  is 
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the  reactive  property  of  the  Controlled  Domain  that  makes  it  amenable 
to  control  by  the  Controller. 

•  The  Required  Behaviour  is  a  constraint  on  the  events  and  states  of  the 
Controlled  Domain.,  which  the  Controller  is  required  to  maintain:  for 
example,  that  the  barrier  should  be  down  whenever  a  train  is  in  the 
vicinity  of  the  crossing. 

To  solve  a  problem  fitting  the  Control  frame  it  is  necessary  to  consider  the 
autonomous  events  of  the  Controlled  Domain  and  determine  the  appropriate 
response  of  the  Controller  to  bring  about  or  maintain  the  Required  Behaviour. 
It  may  be  necessary  to  implement  a  model  of  the  Controlled  Domain  inside 
the  System,  to  allow  appropriate  responses  to  be  determined  at  execution 
time. 


2.2  Static  Information  Frame 

The  Static  Information  problem  frame  might  be  used  for  a  simple  Bible 
concordance  system.  It  has  five  parts: 

•  The  System,  which  is  the  machine  to  be  built. 

•  The  Subject  Domain,  which  is  a  static  part  of  the  world,  not  connected 
to  the  System.  Because  it  is  static,  it  has  a  fixed  state  and  no  events: 
the  text  of  the  Bible  is  not  subject  to  change. 

•  The  Association  Events,  which  form  an  unstructured  stream  of  events 
in  which  associations  are  defined  between  the  phenomena  of  the  Subject 
Domain  and  the  phenomena  of  the  System.  These  events  are  not  events 
in  the  Subject  Domain  of  the  Bible  text.  They  are  events  in  a  set-up 
procedure  by  which  the  System  acquires  an  internal  model  of  the  Bible 
text. 

•  The  Information  Requests,  which  are  an  unstructured  set  of  questions 
and  associated  responses  about  the  Subject  Domain.  For  example,  a 
question  might  be  “Where  do  the  names  Cain  and  Abel  occur  in  the 
same  verse?” .  In  the  implementation  of  the  System  a  question  and  its 
response  might  be  a  function  invocation  and  result;  or  the  reading  of 
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an  input  message  and  writing  of  an  output  reply;  or  simply  the  access¬ 
ing  of  an  internal  data  structure  of  the  System  by  another  application 
program. 

•  The  Information  Rules,  which  are  required  relationships  between  the 
Subject  Domain  and  the  Information  Requests.  For  example,  the  mean¬ 
ing  of  ‘in  the  same  verse’  is  to  be  interpreted  in  a  certain  way  in  terms 
of  the  text  of  the  Bible. 

Solving  a  Static  Information  problem  typically  requires  that  the  System 
should  have  an  internal  model  of  the  Subject  Domain.  The  model  may  be 
implemented  by  an  internal  data  structure,  by  a  database,  and  in  many  other 
ways.  The  Association  Events  initialise  this  model;  subsequently  the  System 
uses  the  model  but  does  not  update  it. 

2.3  Dynamic  Information  Frame 

The  Dynamic  Information  problem  frame  might  be  used  for  monitoring  the 
traffic  using  a  segment  of  road.  The  frame  has  four  principal  parts: 

•  The  System,  which  is  the  machine  to  be  built. 

•  The  Subject  Domain,  which  is  a  dynamic  part  of  the  world,  directly 
connected  to  the  System:  sensors  laid  in  the  roadway  ensure  that  the 
passage  of  a  wheel  over  a  certain  line  across  the  road  is  an  event  both 
in  the  System  and  in  the  Subject  Domain.  The  Subject  Domain  is 
entirely  autonomous,  its  dynamic  behaviour  being  unaffected  by  the 
System.  The  behaviour  of  interest  in  the  Subject  Domain  would  be 
the  passage  of  time,  and  the  passage  of  vehicles  over  the  road  segment 
being  monitored. 

•  The  Information  Requests,  which  are  again  an  unstructured  set  of  ques¬ 
tions  and  associated  responses  about  the  Subject  Domain,  and  have  a 
similarly  wide  range  of  possible  implementations.  A  request  might  con¬ 
cern  the  rate  of  increase  of  traffic  in  the  road  segment  in  a  particular 
time  period. 

•  The  Information  Rules,  which  are  required  relationships  between  the 
behaviour  of  the  Subject  Domain  and  the  Information  Requests.  For 
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example,  certain  patterns  of  wheel  pulses  are  to  be  interpreted  as  the 
passage  of  a  three-axle  vehicle. 

A  problem  fitting  the  Dynamic  Information  frame  requires  the  System  to 
collect  and  maintain  information  from  the  autonomous  events  in  the  Subject 
Domain.  This  information  is  needed  for  responding  to  the  Information  Re¬ 
quests.  It  may  take  the  form  of  an  elaborate  model  of  the  changing  state 
of  the  Subject  Domain.,  or  may  be  little  more  than  a  record  of  selected  past 
events. 

In  the  following  section  we  describe  our  example  problem  and  decompose 
it  into  three  subproblems  that  fit  the  frames  given  above. 

3  An  Example  Problem 

Our  example  is  adapted  from  a  well-known  problem  discussed  by  Swartout 
and  Balzer  [11,  1].  It  concerns  the  control  of  a  package  router. 

3.1  Problem  Statement 

A  package  router  consists  of  a  binary  tree  of  pipes  through  which  packages 
slide  by  gravity  to  destination  bins,  passing  through  two-position  switches 
that  can  be  set  to  direct  them  to  the  right  bins.  A  reading  station  detects  the 
bar-coded  destination  of  each  package  on  entry  to  the  machine.  The  system 
must  control  the  router  by  setting  the  switch  positions  appropriately. 

Each  pipe  has  sensors  at  its  top  and  bottom,  which  close  when  the  leading 
edge  of  a  package  arrives  and  open  when  its  trailing  edge  leaves.  The  pipes 
are  bent  in  the  vicinity  of  the  sensors,  so  that  the  sensors  are  guaranteed  to 
detect  each  passing  package,  no  matter  how  closely  the  packages  follow  one 
another.  Package  size  is  restricted  so  that  no  overtaking  is  possible,  either  in 
the  pipes  or  in  the  switches. 

A  switch  may  be  reset  only  when  no  package  is  present  between  its  in¬ 
coming  and  outgoing  pipes.  Because  packages  slide  at  unpredictable  rates, 
a  package  may  follow  another  too  closely  for  correct  setting  of  a  switch.  A 
wrongly  routed  package  may  be  routed  to  any  bin:  a  message  is  displayed 
showing  the  intended  and  actual  destinations. 
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3.2  Problem  Frames  for  the  Package  Router 

At  first  sight  the  whole  problem  appears  to  fit  into  the  Control  problem  frame. 
The  router  equipment,  with  the  packages,  forms  the  Controlled  Domain;  the 
machine  we  are  to  build  is  the  Controller.  As  required  by  the  problem  frame, 
the  machine  is  directly  connected  to  the  router:  it  can  detect  the  current 
settings  of  the  switches  and  any  change  of  state  in  a  sensor;  it  can  detect 
the  reading  of  a  bar-coded  destination  and  the  value  read;  and  it  can  flip 
a  switch  or  display  a  message  by  executing  appropriate  procedures.  The 
Required  Behaviour  is  that  each  package  should  either  find  its  way  to  its 
proper  destination  or  have  its  misrouting  appropriately  notified  by  a  message. 

However,  the  problem  is  a  little  more  complex  than  this.  The  connections 
provide  no  information  about  the  configuration  of  the  pipes,  sensors,  switches 
and  bins.  The  machine  can  detect  a  change  in  a  sensor  state,  but  it  has  no 
way  of  knowing  where  that  sensor  is  in  the  tree  of  router  pipes.  It  can  flip  a 
switch,  but  it  has  no  way  of  knowing  where  that  switch  is  in  relation  to  the 
sensors  and  bins.  This  information  is  essential  for  controlling  the  router,  and 
must  come  from  some  kind  of  set-up  procedure,  which  creates  an  internal 
model  of  the  topology  of  the  router.  In  addition  to  the  Control  frame  we 
therefore  need  a  Static  Information  frame. 

There  is  a  further  complexity.  The  destination  of  each  package  is  read 
just  once,  from  its  bar-coded  label,  by  the  reading  station.  When  the  package 
is  detected  by  each  sensor  in  its  subsequent  journey  through  the  router,  there 
is  nothing  to  associate  the  package  directly  with  its  destination:  the  label  is 
not  read  again  at  each  sensor.  It  is  therefore  necessary  to  deduce  the  package 
destination  from  what  is  known  about  the  topology  of  the  router  and  the  way 
the  packages  flow  through  it.  This  problem  fits  into  the  Dynamic  Information 
problem  frame. 

The  problem  of  controlling  the  router  may  therefore  be  decomposed  into 
three  subproblem  views.  One  subproblem  view  fits  the  Control  frame:  we 
will  call  this  the  Switch  Control  view.  One  fits  the  Dynamic  Information 
frame:  we  will  call  this  the  Package  Tracking  view.  The  third  fits  the  Static 
Information  frame:  we  will  call  this  the  Router  Topology  view. 
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3.3  Adequacy  of  a  Problem  Frame 

None  of  the  three  problem  frames  we  have  described  is  alone  enough  to  solve 
the  whole  problem.  The  Static  Information  frame  can  not  possibly  deal 
with  the  dynamic  aspects  of  the  problem.  The  Dynamic  Information  frame 
lacks  an  effective  set-up  procedure.  It  also  assumes  that  its  Subject  Domain 
is  entirely  autonomous  and  unaffected  by  the  System,  and  therefore  lacks 
provision  for  describing  a  Required  Behaviour  of  the  Subject  Domain  and  any 
actions  by  which  the  System  might  bring  it  about. 

Of  course,  the  limitations  of  a  problem  frame  can  be  ignored,  and  the 
problem  forced,  in  the  fashion  of  Procrustes,  into  an  unsuitable  mould.  This 
is  often  done.  For  example,  JSD,  which  is  essentially  a  method  for  Dynamic 
Information  problems,  has  been  pressed  into  service  to  solve  problems  that 
would  fit  far  better  into  the  Control  frame  [5].  We  are  accustomed  to  this 
kind  of  fudging,  and  expect  to  devote  some  effort  to  finding  work-arounds. 
But  this  cavalier  unconcern  for  the  nature  and  structure  of  a  problem  is  not 
a  recipe  for  successful  development. 

4  Router  Topology  View 

The  Router  Topology  view  fits  the  Static  Information  problem  frame.  The 
principal  parts  are  these: 

•  The  System  is,  of  course,  the  machine  we  are  developing. 

•  The  Subject  Domain  is  the  static  configuration  of  the  router  equipment. 
The  current  settings  of  the  switches  and  the  current  locations  of  the 
packages  are  not  a  part  of  the  Subject  Domain  in  this  view. 

•  The  Association  Events  are  the  events  of  a  set-up  procedure  in  which 
the  System  receives  the  information  it  needs  about  the  router:  which 
sensors  are  attached  to  which  pipes;  which  pipes  enter  and  leave  each 
switch;  and  so  on.  This  set-up  procedure  would  be  performed  when  the 
physical  components  of  the  router  are  initially  configured,  and  when¬ 
ever  the  configuration  is  changed. 

•  The  Information  Requests  are  the  interactions  between  this  subproblem 
view  and  the  other  subproblem  views,  in  which  it  provides  information 
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about  the  router’s  static  configuration;  for  example,  the  position  of  a 
particular  sensor  in  relation  to  its  pipe,  and  whether  a  particular  bin 
can  be  reached  from  a  particular  switch. 

•  The  Information  Rules  are  the  relationships  between  the  Subject  Do¬ 
main  and  the  Information  Requests  that  assure  correctness  of  the  an¬ 
swers.  For  example,  the  router  is  a  directed  tree  in  which  the  leaves  are 
reachable  from  the  root  but  the  root  is  not  reachable  from  the  leaves. 

For  reasons  of  brevity,  we  will  omit  any  account  of  the  Association  Events 
and  the  set-up  procedure.  The  set-up  procedure  produces  a  model  of  the 
Subject  Domain  inside  the  System.  That  is,  it  produces  an  arrangement 
of  machine  phenomena — data  structures  and  values  of  variables—  that  is 
isomorphic  to  the  Subject  Domain.  The  System  then  uses  this  model  to 
answer  the  questions  posed  in  the  Information  Requests. 

We  will  assume  that  the  router  equipment  has  been  assembled;  that  the 
set-up  procedure  has  been  performed;  and  that  the  model  has  been  con¬ 
structed.  We  restrict  ourselves  to  describing  the  Subject  Domain  and  the 
Information  Requests  and  Information  Rules. 

The  RouterDomain  schema  below  is  a  description  both  of  the  model  inside 
the  System  and  of  the  Subject  Domain — the  router — itself.  The  individual 
parts  of  the  router  are  its  pipes,  switches,  bins,  and  sensors.  These  parts 
are  related  in  certain  ways.  Each  sensor  is  located  on  one  pipe,  at  either  its 
upwards  or  its  downwards  end.  Each  switch  has  a  pipe  entering  it,  and  a 
left  and  a  right  pipe  leaving  it.  There  is  a  top  pipe,  into  which  packages  flow 
on  leaving  the  reader.  It  enters  a  switch.  Each  pipe  either  enters  a  switch 
or  terminates  at  (fills)  a  bin.  The  whole  configuration  of  pipes  forms  a  tree 
whose  root  is  the  top  pipe  and  whose  leaves  are  pipes  terminating  at  bins. 

(Notice  that  we  have  chosen  to  treat  the  reader  as  if  it  were  a  sensor, 
although  it  is  not  attached  to  any  pipe;  this  distortion  of  reality  is  discussed 
later  in  the  paper.) 

[SWITCH,  PIPE,  BIN,  SENSOR] 
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_ RouterDomain _ 

top  :  PIPE 
reader  :  SENSOR 

sensUp,  sensDn  :  PIPE  SENSOR 
enters  :  PIPE  >+^  SWITCH 
pipeL.pipeR  :  SWITCH  ^  PIPE 
fills  :  PIPE  >+^  BIN 

reader  ^  ran ( sens U  sensDn) 
top  G  dom  enters 
dom  enters  fl  dom  fills  =  0 
ran  sens  Up  fl  ran  sensDn  =  0 
ran  pipeL  fl  ran  pipeR  =  0 

T&npipeL  U  izm  pipeR  =  (dom  enters\{top})  U  dom  fills 


The  Information  Requests  will  come  from  two  sources: 

1.  The  Switch  Control  view  must  control  the  flow  of  packages  by  setting 
the  switches.  It  therefore  needs  to  determine: 

•  for  each  sensor,  whether  the  sensor  guards  the  entrance  to  a  switch 
(so  that  a  package  that  has  just  passed  that  sensor  is  entering  the 
switch)  and,  if  so,  which  one;  and 

•  for  each  switch  and  each  destination  bin,  whether  the  way  to  the 
bin  lies  through  the  left  or  right  pipe  of  the  switch. 

2.  The  Package  Tracking  view  needs  enough  information  to  keep  track 
of  each  package  in  its  journey  through  the  router.  Since  the  Router 
Topology  view  is  concerned  only  with  the  static  configuration  of  the 
router,  it  can  provide  no  information  about  current  switch  settings. 
The  information  it  provides  is  the  form  of  a  precedes  relation:  given  a 
sensor  S  (other  than  the  reader),  it  identifies  the  sensor  (possibly  the 
reader)  that  precedes  S  in  the  tree. 

We  specify  the  Information  Requests  and  the  Information  Rules  together 
in  two  schemas.  The  first  establishes  some  useful  definitions;  the  second 
specifies  the  guards,  way  and  precedes  relations. 
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_ RouterStaticInformation - 

RouterDomain 

flow  :  PIPE  ^  PIPE 

reachL^  reachR  :  SWITCH  <— )■  BIN 

flow  =  enters  5  {pipeL  U  pipeR) 
reachL  —  pipeL  9  flow*  ?  fills 
reachR  —  pipeR  9  flow*  9  fills 


best  ==  BIN 
DIR  -.—  LI  R 


_ RouterRequestsAndRules - 

RouterStaticInformation 
guards  ;  SENSOR  SWITCH 
way  ;  {SWITCH  x  BEST)  ^  DIR 
precedes  :  SENSOR  -H-  SENSOR 

guards  =  sensDn**  |  enters 
way  =  {reachL  x  {L})  U  {reachR  x  {/?}) 
precedes  =  {reader  i->  sensUp{top)}  U 
{;?  :  PIPE  •  sensUp{p)  i->  sensDn{p)}  U 
{(p,  p')  G  flow  •  sensDn{p)  i-)-  sensUp{p')} 


5  Package  Tracking  View 

The  Package  Tracking  view  fits  the  Dynamic  Information  problem  frame. 

The  principal  parts  are  these: 

•  The  System  is,  of  course,  the  machine  we  are  developing. 

•  The  Subject  Domain  is  a  dynamic  view  of  the  router  and  the  packages 
flowing  through  it.  The  relevant  events  in  the  router — essentially,  the 
reading  of  a  package  destination  or  the  detection  of  a  package  by  a 
sensor — are  directly  connected  to  the  System:  that  is,  each  event  is  both 
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an  event  in  the  router  and  an  event  in  the  machine  that  is  tracking  the 
packages.  The  effect  of  each  relevant  event  in  the  machine  is  to  update 
an  internal  model  of  the  package  locations;  this  model  is  used  to  satisfy 
the  Information  Requests. 

•  The  Information  Requests  provide  information  about  the  dynamic  be¬ 
haviour  of  the  router  and  packages. 

•  The  Information  Rules  are  the  relationships  between  the  Subject  Do¬ 
main  and  the  Information  Requests  that  assure  correctness  of  the  in¬ 
formation  given.  For  example,  because  packages  do  not  overtake  one 
another  in  pipes  or  switches,  the  packages  in  one  pipe  or  one  switch 
form  a  FIFO  queue. 

The  information  to  be  provided  is  essentially  an  interpretation  of  each 
event  in  the  journey  of  each  package.  When  a  package  passes  a  sensor,  the 
Switch  Control  view  may  need  to  determine: 

1.  What  is  the  destination  of  the  package?  and 

2.  If  the  package  has  reached  a  switch,  is  the  switch  empty? 

The  internal  model  maintained  by  the  Package  Tracking  view  consists  of 
queues  of  packages  (represented  only  by  their  destinations).  One  queue  is 
associated  with  each  sensor,  excluding  those  sensors  that  lead  directly  into 
bins.  Once  a  package  has  passed  into  a  bin  it  will  be  of  no  further  interest. 

This  model  is  sufficient  to  answer  the  questions  above.  It  does  not  require 
information  about  the  settings  of  switches  in  the  router,  since  it  relies  only 
on  determining  which  queue  a  package  is  leaving  when  it  arrives  at  the  next 
sensor.  It  does,  of  course,  depend  on  information  about  the  router  configu¬ 
ration,  obtained  from  the  Router  Topology  view.  In  the  Package  Tracking 
view,  this  information  appears  in  the  schema  below  as  declarations  of  the 
variables  precedes.,  bin  and  reader.  The  values  of  these  variables  are  uncon¬ 
strained  in  this  view,  and  will  be  determined  when  the  view  is  connected  to 
the  Router  Topology  view. 
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_ Package  TrackingDomain - 

queue  :  SENSOR  ^  seq  BEST 
precedes  :  SENSOR  -+->  SENSOR 
bin  :  SENSOR  -o  BIN 
reader  :  SENSOR 


The  queue  model  must  be  initialised.  A  Static  Information  model  is 
initialised  by  the  Association  Events  in  its  set-up  procedure.  For  a  Dynamic 
Information  model  there  may  in  some  cases  be  an  appropriate  initial  event  in 
the  Subject  Domain,  but  this  is  unusual.  More  often,  as  here,  it  is  necessary 
to  define,  and  have  the  System  execute,  a  special  initialisation  event.  The 
model  is  initialised  by  setting  all  its  queues  to  the  empty  sequence: 

_ Init-Package  TrackingDomain -  - - 

Package  TrackingDomain' 

queue'  =  (domain)  {SENSOR  x  ()) 


The  queue  model  is  maintained  by  updating  on  each  of  the  following 
events: 

•  Transfer,  in  which  a  package  passes  from  the  upper  to  the  lower  sensor 
of  the  same  pipe,  or  from  the  entry  pipe  of  a  switch  to  one  of  its  exit 
pipes; 

•  ReadDest,  in  which  the  package  passes  the  reader  and  its  destination  is 
read;  and 

•  Deposit,  in  which  a  package  arrives  at  a  bin. 

In  the  schemas  describing  these  events  we  need  not  constrain  the  relations 
precedes,  bin  and  reader  to  remain  unchanged  by  the  events.  They  will  be 
constrained  appropriately  when  the  views  are  connected  together. 

A  Transfer  event  is  one  in  which  a  package  passes  a  sensor  that  is  not 
the  reader  and  does  not  lead  to  a  bin.  A  Transfer  event  causes  the  model  to 
be  updated  by  moving  the  transferred  package  from  the  head  of  the  queue  it 
is  leaving  to  the  end  of  the  queue  it  is  joining.  The  value  of  the  destination 
d  in  a  Transfer  event  is  determined  from  the  queue  model:  the  destination 
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is  always  that  of  the  package  at  the  head  of  the  queue  associated  with  the 
preceding  sensor,  because  that  is  the  package  being  transferred. 

_ Transfer _ _ _ 

APackageTrackingDomain 
se  ;  SENSOR 
d  :  BEST 

St  7^  reader  A  se  ^  dom  bin 
d  —  head  queue  (precedes (se)) 
queue'  =  queue® 

{precedes[se)  tail  queue(precedes(se)) , 
se  1-4  queue{se)  (d)} 


A  ReadDest  event  is  one  in  which  a  package  passes  the  sensor  that  is  the 
reader.  A  ReadDest  event  causes  the  model  to  be  updated  by  adding  the 
package  just  read  (represented  by  its  destination)  to  the  end  of  the  queue 
associated  with  the  reader.  The  value  of  the  destination  d  in  a  ReadDest  event 
is  determined  from  the  state  shared  between  the  router  and  the  Controller. 

_ ReadDest  _ _ _ 

APackage  TrackingDomain 
se  :  SENSOR 
d  :  BEST 

se  =  reader 

queue'  =  queue  0  {reader  i-4-  queue{reader)  (d)} 


A  Deposit  event  is  one  in  which  a  package  passes  a  sensor  that  leads  to 
a  bin,  into  which  the  package  is  then  deposited.  A  Deposit  event  causes  the 
model  to  be  updated  by  removing  the  deposited  package  from  the  queue  it 
has  just  left.  The  value  of  the  destination  d  in  a  Deposit  event  is  determined 
from  the  queue  model.  The  value  of  the  bin  b  reached  is  calculated  from  the 
bin  relation. 


16 


_ Deposit  - - — - 

A  Package  Tracking  Domain 
se  :  SENSOR 
d  :  DEST 
b  :  BIN 

se  G  dom  bin  A  b  =  bin{se) 
d  =  \\e^d{queue{precedes{se)) 

queue'  =  queue  ©  {precedes{se)  ^  tail  queue{precedes{se))} 


A  package  is  deposited  in  the  right  bin  if  the  sensor  it  has  just  passed  is 
at  the  entry  to  its  destination  bin.  Otherwise  it  is  deposited  in  a  wrong  bin, 
and  a  message  must  be  displayed. 

_ RightBin  - - 

Deposit 

b  =  d 


_ WrongBinMessage  — 

Deposit 

actual.,  desiredl  :  BIN 
b  ^  d 

desired]  =  d 
actual]  =  b 


6  Switch  Control  View 

The  Switch  Control  view  fits  the  Control  frame.  The  principal  parts  are 
these: 

•  The  Controller  is,  of  course,  the  machine  we  are  developing. 

•  The  Controlled  Domain  is  the  router  switches  and  the  packages  flowing 
through  them.  The  autonomous  aspect  of  the  Controlled  Domain  is  the 
package  flow:  packages  pass  sensors  under  the  force  of  gravity,  and  the 
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Controller  can  neither  stimulate  nor  inhibit  these  events.  The  reactive 
aspect  of  the  Controlled  Domain  is  that  the  Controller  can  set  the 
router  switches,  and  so  determine  the  path  taken  by  each  package. 

•  The  Required  Behaviour  is  that  each  package  should  be  directed  along 
a  path  to  the  destination  given  in  its  bar-coded  label,  subject  to  the 
overriding  rule  that  no  switch  may  be  reset  while  it  contains  any  pack¬ 
age. 

The  Controller  is  connected  to  the  router  by  two  classes  of  shared  event 
and  by  a  shared  state.  The  shared  state  is  the  current  setting  of  each  switch. 
At  any  time,  each  switch  is  set  either  in  the  L  or  in  the  R  direction,  and 
this  state  is  shared  with  the  Controller,  perhaps  by  a  DMA  connection.  The 
shared  state  is  simply: 

_ SwitchSettings _ 

setting  :  SWITCH  — >  DIR 


As  in  the  two  other  views,  the  schema  describing  the  model  is  a  description 
both  of  the  state  of  the  Controlled  Domain  and  of  a  part  of  the  internal 
model  to  be  maintained  by  the  Controller. 

The  shared  events  are  ArriveAtSwitch  and  FlipSwitch: 

•  ArriveAtSwitch  events  are  autonomous  events  in  the  Controlled  Do¬ 
main,  in  which  a  package  arrives  at  a  switch. 

•  FlipSwitch  events  are  initiated  by  the  Controller.  In  a  FlipSwitch  event 
the  direction  of  a  switch  is  reversed  (from  L  to  R  or  from  R  to  L). 

For  each  ArriveSwitch  event  that  occurs,  the  Controller  must  determine 
whether  a  FlipSwitch  event  should  occur  in  response.  To  do  so,  it  may  need 
to  determine; 

•  the  current  setting  of  the  switch; 

•  the  destination  of  the  arriving  package; 

•  the  appropriate  switch  setting  for  the  destination;  and 

•  whether  the  switch  is  currently  empty. 
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The  current  setting  of  the  switch  is  directly  available  from  the  shared 
state  SwitchSettings.  In  the  schema  below,  the  appropriate  switch  setting 
for  a  destination  is  declared  as  an  unconstrained  variable  choice.  In  this 
frame  we  need  not  constrain  choice  in  any  way.  We  may  leave  open  all  the 
possibilities,  namely  that  it  is: 

•  a  total  function:  there  is  exactly  one  path  to  a  given  bin  from  a  given 
switch; 

•  a  partial  function:  there  is  one  path,  or  no  path,  to  a  given  bin  from  a 
given  switch;  or,  most  generally, 

•  a  relation:  there  is  one  path,  no  path,  or  more  than  one  path  to  a  given 
bin  from  a  given  switch. 

By  treating  choice  as  a  relation  we  leave  all  the  possibilities  open  in  this 
view.  (When  we  come  to  connect  this  view  with  the  Router  Topology  view 
we  will  see  that  choice  is  a  partial  function;  but  if  paths  through  the  router 
could  merge,  then  choice  would  have  to  be  an  unrestricted  relation.) 

Another  unconstrained  variable  in  the  schema  is  empty:  this  is  the  set  of 
currently  empty  switches.  The  values  of  choice  and  empty  will  be  determined 
when  the  views  are  connected  together.  Together  with  SwitchSettings  they 
constitute  the  model  of  the  Controlled  Domain  available  to  the  Controller. 

_ SwitchesModel - - - — 

SwitchSettings 

choice  :  {SWITCH  X  DEST)  ^  DIR 
empty  :  P  SWITCH 


An  ArriveAtSwitch  event  involves  the  switch  where  the  arrival  has  oc¬ 
curred,  and  the  destination  of  the  arriving  package.  We  distinguish  two 
kinds  of  ArriveAtSwitch  event,  according  to  whether  the  Controller  responds 
by  flipping  the  switch.  (Although  the  arrival  and  the  response  are  distinct 
events  in  the  real  world,  it  is  appropriate  and  convenient  in  Z  to  treat  them 
as  a  single  event.  This  distortion  of  reality  is  discussed  later  in  the  paper.) 

The  Required  Behaviour  demands  that  the  switch  direction  should  be 
changed  only  if  the  switch  is  empty,  and  only  if  the  changed  direction  would 
offer  a  path  where  the  current  direction  would  not.  There  is  no  point  in 
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changing  the  direction  of  the  switch  for  a  package  for  which  choice  specifies 
no  appropriate  direction:  the  package  is  already  irretrievably  misrouted. 

flipped  :  DIR  DIR 

flipped  (R)  =  L 
flipped  (L)  =  R 

_ ArriveAndFlip _ 

ASwitchModel 
sw  :  SWITCH 
d  :  DEST 

sw  G  empty 

choice (jsw,  d[)  =  {flipped{setting{sw)y} 
setting'  =  setting  0  {stc  flipped{setting{sw))} 


_ ArriveNoFlip _ 

ASwitchModel 
sw  :  SWITCH 
d  :  DEST 

pre  ArriveAndElip 
setting'  =  setting 


7  Connections 

The  fundamental  connection  technique  for  the  components  of  a  parallel  de¬ 
composition  is  logical  conjunction  [12].  For  a  Z  specification  this  means 
combining  schemas  by  including  one  within  another,  or  by  the  conjunction 
operation  of  the  Z  schema  calculus.  It  is  then  possible  to  impose  additional 
invariants  to  constrain  the  components  of  the  combined  schemas. 

7.1  State  Connections 

The  schema  below,  prefaced  by  the  necessary  declarations,  includes  the  model 
parts  of  the  three  views  of  the  Package  Router  Control  problem,  and  specifies 
the  invariants  that  must  hold  among  them.  These  are: 
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•  precedes  in  the  PackageTrackingDomain  has  the  same  value  as  precedes 
in  the  RouterRequestsAndRules.  This  need  not  be  specified  explicitly, 
because  the  two  relations  have  the  same  name.  In  Z  schema  inclusion 
this  implies  that  they  denote  the  same  thing. 

•  reader 'm  the  PackageTrackingDomain  has  the  same  value — that  is,  it  is 
the  same  SENSOR— as  reader  in  the  RouterRequestsAndRules.  Again, 
this  need  not  be  specified  explicitly,  because  the  two  variables  have  the 
same  name. 

•  bin  in  the  Package  TrackingDomain  has  the  value  determined  by  sensDn 
and  fills  in  the  RouterRequestsAndRules:  a  sensor  leads  to  a  bin  if  it  is 
the  lower  sensor  of  the  pipe  that  fills  the  bin. 

•  choice  in  the  SwitchesModel  has  the  same  value  as  way  in  the  Router¬ 
RequestsAndRules. 

•  empty  in  the  SwitchesModel  has  the  value  determined  by  the  queue 
model  in  the  PackageTrackingDomain.  A  switch  is  empty  if  the  queue 
associated  with  the  sensor  leading  into  it  is  empty.  The  association 
between  switches  and  sensors  is  determined  by  the  relation  guards  in 
the  Router  Topology  view. 

[SWITCH,  PIPE,  BIN,  SENSOR] 

DEST  ==  BIN 
DIR  ■.■.=  L\R 


_ PackageRouter  Control - 

RouterRequestsAndRules 
Package  TrackingDomain 
SwitchesModel 

bin  —  sensDn^  ,  fills 
choice  =  way 

empty  =  guards  (|  dom(gueue  O  ()P 
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7.2  Event  Connections 


The  Init—PackageTrackingDomain  event  is  to  be  executed  by  the  machine 
before  any  other  event  occurs  in  the  router  operation.  It  is  already  fully 
specified  in  the  Package  Tracking  view,  and  need  only  be  promoted  to  an 
operation  on  the  PackageRouterControl  state. 

The  events  involving  the  fiow  of  packages  through  the  router  are  all  sub¬ 
classes  of  a  more  general  event  class,  in  which  a  package  passes  a  sensor.  The 
physical  connection  between  the  router  and  the  machine  indicates  which  sen¬ 
sor  has  been  passed,  but  other  arguments  of  these  events  must  be  determined 
from  the  relevant  model  states. 

The  whole  set  of  events  may  be  classified  like  this: 

•  The  Init—PackageTrackingDomain  event. 

•  PassSensor  events,  each  of  which  is: 

—  a  ReadDest  event;  or 

—  a  Deposit  event  that  is  also  a  RightBin  event;  or 

—  a  Deposit  event  that  is  also  a  WrongBinMessage  event;  or 

—  a  Transfer  th&t  is  also  an  ArriveAndFlip  event;  or 

—  a  Transfer  that  is  also  an  ArriveNoFlip  event. 

ReadDest  events  are  fully  determined  in  the  Package  Tracking  view.  As 
mentioned  in  Section  4  above,  the  value  of  the  destination  d  in  a  ReadDest 
event  is  determined  by  the  state — perhaps  a  machine  register — shared  by  the 
reader  and  the  machine. 

Similarly,  WrongBinMessage  and  RightBin  events  are  also  fully  deter¬ 
mined  in  the  Package  Tracking  view,  where  their  specifications  include  the 
specification  of  the  more  general  Deposit  event  class:  each  WrongBinMessage 
and  each  RightBin  event  is  also  a  Deposit  event.  The  values  of  actual!  and 
desired!  in  WrongBinMessage  events  are  determined  from  the  sensor  se  of 
the  Deposit  event  and  the  queue  model  of  the  PackageTrackingDomain. 

However,  ArriveAndFlip  and  ArriveNoFlip  events  are  not  fully  deter¬ 
mined  by  the  Switch  Control  view  in  which  they  are  specified.  Each  of  these 
events  is  also  a  Transfer  event,  specified  in  the  Package  Tracking  view.  The 
values  of  their  switch  sw  and  destination  d  components  must  be  determined 
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from  the  sensor  se  of  the  Transfer  event,  using  information  from  the  Router 
Topology  view.  So  we  need  schemas  for  the  two  combinations: 

flipped  :  DIR  DIR 

flipped  (R)  =  L 
flipped[L)  —  R 


_ Transfer  AndFlip - 

'ERouterRequestsAndRules 

Transfer 

ArriveAndFlip 

(se  sw)  G  guards 
d  =  head  queue(precedes{se)) 


_ TransferNoFlip - 

'ERouterRequestsAndRules 

Transfer 

ArriveNoFlip 

(se  sw)  €  guards 
d  —  head  queue{precede${se)) 


Now  we  can  define  the  events  as  operations  on  the  PackageRouter Control 
state,  and  write  the  necessary  event  classification: 

Init-PackageRouterControl  = 

APackageRouterControl  A  ERouterRequestsAndRules  A 
Init— Package  TrackingDomain 


PassSensor  = 

APackageRouterControl  A  ERouterRequestsAndRules  A 
( ReadDest  V  WrongBinMessage  V  RightBin  V 
Transfer  AndFlip  V  TransferNoFlip) 
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8 


Discussion 


8.1  Problem  Frames 

The  original  motivation  of  the  idea  of  problem  frames  was  chiefly  method¬ 
ological  [6].  A  problem  frame  bounds  a  class  of  problem  for  which  an  effec¬ 
tive  and  systematic  method  is  known.  The  method  can  be  readily  applied 
to  a  problem  of  the  class  because  the  method  is  expressed  in  terms  of  the 
principal  parts  of  the  problem.  The  JSD  method,  for  example  [5],  treats  Dy¬ 
namic  Information  problems.  In  JSD  the  first  step  is  to  describe  the  Subject 
Domafn— which  in  JSD  is  called  the  Real  World —  as  a  collection  of  concur¬ 
rent  sequential  processes  each  with  a  regular  structure.  The  same  process 
descriptions  are  then  used  to  construct  a  model  of  the  Subject  Domain  within 
the  System.  In  a  later  step,  further  processes  are  added  for  handling  the  In¬ 
formation  Requests  in  accordance  with  the  Information  Rules:  in  JSD  these 
parts  are  called  the  Function  of  the  System. 

This  association  of  problem  frames  with  methods  goes  some  way  to  filling 
the  gap  between  teaching  problems  and  realistic  problems.  A  teaching  prob¬ 
lem  is  an  exercise  in  the  application  of  a  highly  circumscribed  method.  For 
example,  students  of  abstract  data  type  specification  may  first  discuss  a  spec¬ 
ification  of  a  stack;  then  they  are  asked  to  write  their  own  specifications  of  a 
queue,  or  of  a  bag,  or  of  a  double-ended  queue.  Similarly,  students  of  finite 
automaton  theory  may  solve  problems  in  which  deterministic  machines  are 
derived  from  non-deterministic  machines,  or  from  regular  grammars.  These 
problems  are  not  trivial,  but  they  fall  clearly  into  the  classes  that  can  be 
solved  by  the  techniques  being  taught. 

But  such  teaching  problems,  and  the  associated  techniques,  are  not  quite 
large  enough,  and  not  quite  rich  enough,  to  suggest  clearly  identifiable  sub¬ 
problems  in  a  realistically  rich  and  complex  problem.  It  is  not  easy  to  see 
what  abstract  data  types,  and  what  finite  automata,  are  needed  in  an  ac¬ 
counting  system  or  in  a  telephone  switching  system.  Problem  frames  offer 
an  approach  to  analysing  more  complex  problems  like  these,  because  they  of¬ 
fer  structures — ^of  principal  parts — that  can  be  matched  against  the  problem 
domain  or  environment,  and  used  to  identify  aspects — rather  than  parts — of 
the  problem. 
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8.2  Reusability  of  Views 

In  applying  a  frame  to  a  subproblem  view  it  is  helpful  to  imagine  that  the 
other  subproblems  are  already  solved.  Their  solutions  provide  the  context  of 
the  subproblem  in  hand.  For  example,  in  applying  the  Dynamic  Information 
frame  to  the  Package  Tracking  subproblem,  we  imagined  that  the  System — 
the  machine  we  were  building — had  direct  access  to  the  precedes  and  bin 
relations,  and  to  the  identity  of  the  reader  sensor.  In  applying  the  Control 
frame  to  the  Switch  Control  subproblem,  we  imagined  that  the  choice  and 
empty  relations  provided  the  machine  with  directly  accessible  information 
about  the  available  routes  and  the  traffic  in  the  switches;  and  also  that  each 
ArriveAtSwitch  event  directly  indicated  the  identity  of  the  switch  and  the 
destination  of  the  arriving  package. 

The  resulting  decomposition  produced  subproblems  with  a  significant  po¬ 
tential  for  reuse.  In  each  frame  no  more  is  assumed  about  the  problem  con¬ 
text  than  is  necessary  to  the  solution  task  of  the  frame.  Examples  of  this 
indeterminacy  have  already  been  pointed  out,  but  perhaps  have  been  some¬ 
what  masked  by  the  use  of  the  same  names  in  different  views.  For  example, 
the  Package  Tracking  view  might  have  been  expressed  in  terms  of  Travellers 
passing  Checkpoints.  A  Checkpoint  may  serve  as  a  Startpoint  or  Finishpoint, 
but  not  both  at  once.  In  the  complete  problem,  the  Checkpoints.,  of  course, 
are  the  sensors;  a  Startpoint  is  a  reader;  and  a  Finishpoint  is  a  sensor  lead¬ 
ing  to  a  bin.  But  the  Package  Tracking  view  assumes  only  that:  when  a 
Traveller  passes  a  Checkpoint  it  is  known  whether  the  Traveller  is  starting 
or  finishing — that  is,  whether  the  Checkpoint  is  currently  a  Startpoint  or  a 
Finishpoint,  when  it  passes  a  Startpoint  its  desired  Finishpoint  is  known  and 
fixed;  when  it  passes  any  intermediate  Checkpoint  its  previous  Checkpoint  is 
known]  and  that  there  is  no  overtaking  between  Checkpoints. 

The  views  developed  in  our  treatment  of  the  problem  were  not  devised 
with  reuse  in  mind.  Rather,  the  approach  merely  avoided  building  into  each 
view  assumptions  and  features  that  were  irrelevant  to  the  view — and  there¬ 
fore  most  likely  to  inhibit  subsequent  reuse.  The  Switch  Control  view,  for 
example,  deals  only  with  the  events  involving  the  switches.  It  assumes  only 
that:  each  package  arriving  at  a  switch  has  a  destination  that  may  or  may 
not  be  reachable  from  that  switch;  that  there  is  a  constraint  empty  that  may 
preclude  flipping  a  switch;  and  that  if  flipping  is  desirable  and  not  precluded 
the  machine  can  perform  it.  Such  a  subproblem  seems  likely  to  appear  in 
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many  switching  problems,  perhaps  involving  railway  signalling,  control  of 
motor  traffic,  or  even  the  transmission  of  message  packets. 

8.3  Z  Specifications 

Z  seems  especially  well  suited  to  specifications  in  this  style.  Some  of  the  bene¬ 
fits  accrue  from  features  shared  by  many  specification  languages.  The  ability 
to  write  implicit  invariants — shared  with  VDM  and  Larch,  for  instance — is 
crucial  to  describing  the  relationships  between  the  states  of  the  various  views 
without  indicating  how,  in  the  implementation,  the  relationships  are  to  be 
maintained. 

Other  benefits  are  unique  to  Z.  The  underlying  treatment  of  all  functions, 
sequences,  bags,  mappings,  and  so  on,  as  relations  contributes  greatly  to  the 
terseness  of  the  invariants  connecting  the  views,  since  it  obviates  the  need  for 
frequent  type  coercions.  Schema  structuring  is  a  great  help  too.  Since  state 
invariants  and  operations  are  just  logical  assertions,  they  may  be  conjoined 
flexibly  and  simply.  Other  specification  languages  do  not  offer  such  freedom 
of  structuring.  Moreover,  because  the  pre-conditions  of  two  operations  are 
always  composed  (in  the  style  advocated  here)  in  the  same  way  as  the  post¬ 
conditions,  by  conjunction  or  disjunction,  it  is  useful  that  Z  combines  the 
pre-  and  post-condition  of  an  operation  into  a  single  assertion. 

View  specification  does,  however,  expose  some  deficiencies  of  Z.  Most 
significantly,  schema  inclusion  does  not  preserve  the  origin  of  the  state  com¬ 
ponents.  Having  formed  PackageRouter Control,  for  example,  we  cannot  ask 
whether  choice  belongs  to  RouterRequestsAndRules  or  to  PackageTracking- 
Domain.  Schema  inclusion  is  purely  syntactic,  and  the  components  orig¬ 
inating  in  different  schemas  are  thrown  together  in  a  single  unstructured 
namespace.  Intuitively  this  seems  wrong,  since  it  leaves  only  synactic  and 
not  semantic  evidence  of  the  view  structuring  in  the  final  specification.  It  also 
has  serious  pragmatic  implications.  Names  chosen  for  components  belonging 
to  different  views  may  accidentally  clash  when  the  views  are  composed,  and 
the  invariants  relating  components  of  different  views  are  hard  to  read.  We 
could  of  course  adopt  a  convention,  such  as  prefixing  every  name  by  the  name 
of  the  view  it  belongs  to.  It  would  much  better,  however,  for  the  language 
itself  to  provide  some  structuring  of  the  namespace,  so  that  within  a  view 
components  may  have  short  names,  and  in  the  composition  they  are  labelled 
with  the  names  of  their  views. 
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The  type  system  of  Z  is  not  ideal  for  view  specification.  Ideally  we  would 
like  to  treat  a  name  like  SENSOR  sometimes  as  a  set  of  values— taken  from 
an  underlying  type  INDIVIDUAL — and  sometimes  as  a  type.  We  treated 
the  reader  awkwardly  as  a  sensor  in  the  Router  Topology  view,  where  it 
would  have  been  more  natural  to  declare  a  fresh  type  READER,  disjoint  from 
SENSOR.  Strong  typing  of  the  Router  Topology  schemas  would  then  have 
ensured  no  confusion  of  the  reader  with  the  sensors.  The  Package  Tracking 
view,  on  the  other  hand,  associates  queues  with  checkpoints.  In  its  schemas, 
we  therefore  would  like  to  use  a  type  CHECKPOINT. 

In  the  composition  of  the  views,  we  would  then  assert  that  the  checkpoints 
correspond  to  exactly  the  sensors  and  the  reader.  But  unfortunately  the 
assertion 

CHECKPOINT  =  SENSOR  U  READER 

is  a  type  error.  Strong  typing,  it  seems,  is  a  local  property  of  a  view,  and 
should  not  extend  beyond  it.  Z  forces  an  early  decision  of  whether  a  set 
should  be  treated  as  a  type,  seriously  compromising  the  independence  of 
views.  There  are  almost  no  sets  that  can  be  confidently  declared  to  be 
disjoint  without  knowing  which  views  may  be  added  subsequently.  Even 
SWITCH  and  PIPE  and  SENSOR,  for  example,  might  become  subsets  of 
PART  in  a  Maintenance  view  that  keeps  track  of  the  condition  of  the  router’s 
components. 

Finally,  there  is  the  controversial  question  of  the  role  of  convention  in  Z. 
A  schema  is  just  a  logical  assertion,  and  its  standard  interpretation  as  an 
operation  is  not  part  of  the  language  definition.  Our  specification  assumes 
a  number  of  further  conventions  that  we  have  not  articulated  in  detail.  A 
precondition  is  a  guard  and  not  a  disclaimer;  in  bad  states,  it  precludes 
execution  of  the  operation  rather  than  allowing  it  while  insisting  that  its  effect 
is  unspecified.  We  use  conjunction  and  disjunction  of  operation  schemas  to 
classify  events.  Each  operation  schema  name  in  the  definition  of  PassSensor 
denotes  a  set  of  events;  any  particular  event  may  belong  to  more  than  one 
event  class. 


8.4  Integration  Mechanisms 

In  software  development,  which  is  concerned  to  create  machines  that  will 
interact  with  the  world,  the  foundation  of  meaning  must  be  observable  phe- 
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nomena — states  and  events — in  the  machine  and  in  the  parts  of  the  world 
that  constitute  the  application  domain.  The  basis  of  integration — integration 
of  one  view  with  another,  and  integration  of  the  machine  into  the  world — is 
shared  phenomena.  A  shared  event  or  state  occurs  both  in  the  machine  and 
in  the  application  domain;  or  it  is  described  both  in  one  specification  view 
and  in  another. 

Integration  by  shared  phenomena  demands  a  sound  treatment  of  two  as¬ 
pects  of  sharing.  First,  a  shared  phenomenon  is  viewed  differently  by  different 
sharers.  We  have  already  mentioned  the  example  of  the  reader,  which  should 
properly  be  viewed  as  a  unique  individual  of  type  READER  in  the  Router 
Topology  view,  and  as  one  of  many  CHECKPOINTS  in  the  Package  Tracking 
view.  Different  views  and  classifications  of  shared  phenomena  are  simply  a 
microcosm  of  the  different  views  we  adopt  of  larger  aspects  of  the  problem. 

Second,  for  both  shared  events  and  shared  states  it  is  important  to  specify 
the  locus  of  its  control.  The  Init—PackageTracking Domain  event  is  controlled 
by  the  machine;  but  the  ReadDest  and  Transfer  events  are  controlled  by  the 
application  domain.  The  ArriveAndFlip  events  should  really  be  treated  as 
event  pairs;  in  the  first  event  of  each  pair,  controlled  by  the  domain,  a 
package  arrives  at  a  switch;  in  the  second  event,  controlled  by  the  machine, 
the  machine  flips  the  position  of  the  switch.  The  two  events  of  the  pair  are 
combined  in  our  specification,  because  Z  lacks  a  convenient  mechanism  for 
expressing  their  relationship.  The  schema  expressions: 

Arrive  5  Flip 


and 


Arrive  ::$>  Flip 

do  not  describe  pairs  of  operations.  Rather,  they  describe  single  operations 
by  identifying  the  post-state  of  one  schema  with  the  pre-state  of  the  other 
and  hiding  the  linking  state.  Any  notion  that  there  are  two  operations,  one 
following  the  other  in  time,  would  depend  on  interpretation  by  a  special — and 
heterodox — convention,  supported  by  informal  commentary. 

We  believe  that  the  interpretation  of  the  specification  in  terms  of  ob¬ 
servable  phenomena  should  not  be  relegated  to  informal,  unstructured  com¬ 
mentary,  but  should  be  governed,  for  a  given  style  of  specification,  by  well- 
understood  and  precisely  articulated  rules.  This  remains  to  be  done.  As  a 
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first  step,  a  translation  into  a  simpler  formal  model  closer  to  the  observed 
phenomena — such  as  a  labelled  transition  system — might  help.  Such  a  fea¬ 
ture,  combined  with  good  support  for  multiple  views  of  shared  phenomena, 
would  go  far  to  encourage  specification  in  the  style  we  advocate. 
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Appendix 

The  formal  parts  of  the  specification  are  brought  together  here.  They  are 
given  in  the  order  of  their  original  presentation,  except  that  the  following 
declarations  are  given  first,  here: 

[SWITCH,  PIPE,  BIN,  SENSOR] 


BEST  ==  BIN 
DIR  ::=L\R 


flipped  :  DIR  >-»  DIR 

flipped{R)  —  L 
flipped  [L]  =  R 
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Router  Topology  View 

_ RouterDomain - - - — 

top  :  PIPE 
reader  :  SENSOR 

sensUp,  sensDn  :  PIPE  > — SENSOR 
enters  :  PIPE  -+»  SWITCH 
pipeRpipeR  :  SWITCH  PIPE 
fills  :  PIPE  ^  BIN 

reader  ^  ran(sens[/p  U  sensDn) 
top  G  dom  enters 
dom  enters  Pi  dom  fills  —  0 
ran  sensUp  H  ran  sensDn  =  0 
ran  pipe!  Pi  ran  pipeR  =  0 

mnpipeL  U  van  pipeR  —  (dom  enters\{top})  U  dom  fills 


RouterStaticInformation - 

RouterDomain 

flow  :  PIPE  ^  PIPE 

reachLj  reachR  :  SWITCH  >  BIN 

flow  =  enters  |  {pipeL  U  pipeR) 
reachL  =  pipeL  ,  flow*  |  fills 
reachR  =  pipeR  ;  flow*  ?  fills 


_ RouterRequestsAndRules  - - - 

RouterStaticInformation 
guards  :  SENSOR  >+^  SWITCH 
way  :  (SWITCH  x  DEST)  ^  DIR 
precedes  :  SENSOR  — SENSOR 

guards  =  sensDn**  ?  enters 
way  =  (reachL  x  {L})  U  (reachR  x  {/?}) 
precedes  =  {reader  i->-  sensUp(top)}  U 
{p  :  PIPE  •  sensUp(p)  i->-  sensDn(p)}  U 
{(p,p')  e  flow  •  sensDn(p)  sensUp(p')} 
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Package  Tracking  View 

_ Package  TrackingDomain _ 

queue  :  SENSOR  -H-  seq  DEST 
precedes  :  SENSOR  -H-  SENSOR 
bin  :  SENSOR  BIN 
reader  ;  SENSOR 


—  Init— Package  TrackingDomain _ 

Package  TrackingDomain' 

queue'  =  (dom6m)  ^  (SENSOR  x  ()) 


_ Transfer  _ _ 

APackageTrackingDomain 
se  :  SENSOR 
d  :  DEST 

se  ^  reader  /\  se  ^  dom  bin 
d  =  head  queue(precedes(se)) 
queue'  =  queue® 

{precedes(se)  i->  tail  queue(precedes(se)) , 
se  !-)•  queue(se)  (d)} 


—  ReadDest _ _ _ 

APackage  TrackingDomain 
se  :  SENSOR 
d  :  DEST 

se  =  reader 

queue'  =  queue  0  {reader  i->  queue(reader)  ^  (d)} 


32 


_ Deposit  - - - - 

APackage  TrackingDomain 
se  :  SENSOR 
d  :  BEST 
b  :  BIN 

se  €  dom  bin  A  6  =  bin{se) 
d  =  head{queue{precedes{se)) 

queue'  =  queue  ©  {precedes{se)  h-)-  tail  queue{precedes{se))} 


_ RightBin 

Deposit 

b  =  d 


_ WrongBinMessage  — 

Deposit 

actually  desiredl  :  BIN 
b  ^  d 

desiredl  =  d 
actual]  =  b 


Switch  Control  View 

_ SwitchSettings - 

setting  :  SWITCH  DIR 


_ SwitchesModel - — 

SwitchSettings 

choice  :  {SWITCH  X  BEST)  ^  DIR 
empty  :  P  SWITCH 
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_ ArriveAndFlip  _ _ 

ASwitchModel 
sw  :  SWITCH 
d  :  BEST 

sw  E  empty 

choice^sw^d)  =  {flipped  {setting  (sw))} 
setting'  =  setting  ®  {stu  flipped  (setting  {sw))} 


_ A  rriveNoFlip _ 

ASwitchModel 
sw  :  SWITCH 
d  ;  BEST 

-■  pre  ArriveAndElip 
setting'  =  setting 


Connections 

—  PackageRouterControl _ 

Router  Requests  AndRules 
Package  TrackingBomain 
SwitchesModel 

bin  =  sensBn'"  ^  fills 
choice  =  way 

empty  =  guards  (|  dom{queu€  >  ()D 


—  Transfer AndPlip _ 

ERouterRequests  AndRules 

Transfer 

ArriveAndPlip 

{se  1-^  sw)  £  guards 
d  =  head  queue{precedes{se)) 
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_ TransferNoFlip - 

FRouterRequestsAndRules 

Transfer 

ArriveNoFlip 

(se  H- )-  sw)  G  guards 
d  =  head  queue  (precedes (se)) 


Init-PackageRouterControl  = 

APackageRouter Control  A  "FRouter Requests AndRules  A 
Init^Package  TrackingDomain 


PassSensor  = 

APackageRouterControl  A  FRouter Requests AndRules  A 
(ReadDest  V  WrongBinMessage  V  RightBin  V 
TransferAndFlip  V  TransferNoFlip) 
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